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Abstract 

We investigate a technique from the literature, called the phantom-types technique, that 
uses parametric polymorphism, type constraints, and unification of polymorphic types to 
model a subtyping hierarchy. Hindley-Milner type systems, such as the one found in Stan- 
dard ML, can be used to enforce the subtyping relation, at least for first-order values. We 
show that this technique can be used to encode any finite subtyping hierarchy (including 
hierarchies arising from multiple interface inheritance). We formally demonstrate the suit- 
ability of the phantom-types technique for capturing first-order subtyping by exhibiting 
a type-preserving translation from a simple calculus with bounded polymorphism to a 
calculus embodying the type system of SML. 



1 Introduction 

It is well known that traditional type systems, such as the one found in Standard 
ML (Milner et al, 1997), with parametric polymorphism and type constructors, can 
be used to capture program properties beyond those naturally associated with a 
Hindley-Milner type system (Milner, 1978). For concreteness, let us review a simple 
example, due to Leijen and Meijer (1999). Consider a type of atoms, either booleans 
or integers, that can be easily represented with an algebraic datatype: 

datatype atom = I of int I B of bool. 

There are a number of operations that we may perform on such atoms (see Fig- 
ure 1(a)). When the domain of an operation is restricted to only one kind of atom, 
as with conj and double, a run-time check must be made and an error or exception 
reported if the check fails. 

One aim of static type checking is to reduce the number of run-time checks 
by catching type errors at compile time. Of course, in the example above, the 
SML type system does not consider conj (mkint 3, mkBool true) to be ill-typed; 
evaluating this expression will simply raise a run-time exception. 

If we were working in a language with subtyping, we would like to consider integer 
atoms and boolean atoms as distinct subtypes of the general type of atoms and use 
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datatype atom = I of int I B of bool 



fun mkint Ci : int) : atom = I (i) 
fun mkBool (b:bool) :atom = B (b) 
fun toString (v : atom) : string = 
(case V 

of I (i) => Int. toString (i) 
I B (b) => Bool. toString (b)) 
fun double ( v : atom) : atom = 
(case V 

of I (i) => I (i * 2) 
I _ => raise Fail "type mismatch") 
fun conj (vl;atom, 

v2 : atom) : atom = 
(case (vl,v2) 
of (B (bl), B (b2)) => B (bl andalso b2) 
I _ => raise Fail "type mismatch") 

(a) Unsafe operations 



datatype atom = I of int I B of bool 
datatype 'a safe_atom = W of atom 

fun mkInt (i: int): int safe_atom = W CI (i)) 
fun mkBool Cb;bool) ;bool safe_atom = W (B Cb) ) 
fun toString (v:'a safe_atom) : string = 
(case V 

of W (I (i)) => Int. toString (i) 
I W (B (b)) => Bool. toString (b)) 
fun double Cv:int saf e_atom) : int safe_atom = 

(case V 

of ¥ (I (i)) => W (I (i * 2)) 
I _ => raise Fail "type mismatch") 
fun conj (vl:bool atom, 

v2 : bool atom) : bool atom = 
(case (vl,v2) 
of (W (B (bl)), W (B (b2))) => 
W (B (bl andalso b2)) 
I _ => raise Fail "type mismatch") 



(b) Safe operations 



Fig. 1. Atom operations 



these subtypes to refine the types of the operations. Then the type system would 
report, at compile time, a type error in the expression double (mkBool false). 
Fortunately, we can write the operations in a way that utilizes the SML type system 
to do just this. We introduce a new datatype that represents "safe" atoms, which 
is a simple wrapper around the datatype for atoms: 

datatype 'a safe_atom = W of atom 

and constrain the types of the operations (see Figure 1(b)). We use the superfluous 
type variable 'a in the datatype definition to encode information about the kind 
of atom. (Because instantiations of this type variable do not contribute to the run- 
time representation of atoms, it is called a phantom type.) The type int saf e_atom 
is used to represent integer atoms and bool saf e_atom is used to represent boolean 
atoms. Now, the expression conj (mkInt 3, mkBool true) results in a compilc- 
time type error, because the types int safe_atom and bool safe_atom do not 
unify. (Observe that our use of int and bool as phantom types is arbitrary; we 
could have used any two types that do not unify to make the integer versus boolean 
distinction.) On the other hand, both toString (mkInt 3) and toString (mkBool 
true) are well-typed; the toString operation can be applied to any atom. Note 
that we had to wrap the atom type in another datatype; the next section will explain 
why."'^ 

The example above used a datatype as the representation of values manipulated 
by "unsafe" operations, and a wrapped version of the datatype to enforce safety. 

^ We could have simply defined saf e_atom as: 

datatype 'a safe_atom = I of int I B of bool 

but for the sake of uniformity with the techniques presented in the next section, we use the 
slightly more verbose wrapping using a W constructor. 
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type sock = Word32.word 



datatype udp = UDP 
datatype top = TCP 

datatype 'a safe_sock = W of Word32.word 



fun makeUDP Caddr : string) : sock = 

fflMakeUDP (addr) 
fun makeTCP (addr : string) : sock = 

ffiMakeTCP (addr) 



fun makeUDP (addr ; string) : udp safe_sock = 

W (ffiMakeUDP (addr)) 
fun makeTCP (addr:string) :tcp safe_sock = 

W (ffiMakeTCP (addr)) 



fun sendUDP (s ; sock, text : string) :unit = 

ffiSendUDP (s.text) 
fun sendTCP (s : sock, text : string) :unit = 

ffiSendTCP (s,text) 



fun sendUDP (s:udp saf e_sock, text : string) : unit = 
(case s of W (w) => ffiSendUDP (w,text)) 

fun sendTCP (s:tcp saf e_sock, text : string) : unit = 
(case s of W (v) => ffiSendTCP (w,text)) 



fun close (s:sock) :unit = 
ffiClose (s) 



fun close (s:'a saf e_sock) : unit = 
(case s of W (w) => ffiClose (w)) 



(a) Uiisafo operations 



(})) Safe oyjoratioiis 



Fig. 2. Socket operations 



However, the underlying representation need not be a datatype. Consider a common 
instance of the problem, where we wish is to manipulate operating-system values, 
such as sockets. These are typically accessed via a foreign-function interface and 
they arc typically represented by a 32-bit integer value (either representing a pointer 
or a handle in a table kept by the operating system) . A number of primitive opera- 
tions are provided through the foreign-function interface for handling those sockets 
(see Figure 2(a)). However, while the SML representation of a socket is just a 32-bit 
integer, the operating system often distinguishes internally between different kinds 
of sockets, for instance, between UDP sockets and TCP sockets, and operations 
specific to UDP sockets cause run-time exceptions (at the operating-system level) 
when supplied with a TCP socket. For instance, the operation sendUDP expects a 
UDP socket and a string to send on the socket. This is exactly the kind of check 
that occurs in the atom example above, except it is performed automatically by 
the operating system rather than the code. Other operations, such as close, work 
with all sockets, and therefore, there is an implicit subtyping relation among sock- 
ets, UDP sockets, and TCP sockets. We can enforce the appropriate use of sockets 
statically by defining new types: 



and constraining the types of the operations appropriately (see Figure 2(b)). Note 
that we again use a superfiuous type variable in the definition of the type saf e_sock 
to allow us to constrain the type of the operations. We can now supply appropriate 
types to versions of safe operations on sockets. (Note once again that we had to 
wrap the Word32 . word type in a datatype.) 

This is the essence of the technique explored in this paper: using a free type 
variable to encode subtyping information for first-order values, and using an SML- 
like type system to enforce the subtyping on those values. (We focus on first-order 
subtyping in this paper; Section 4 explains why.) This "phantom types" technique. 



datatype udp = UDP 

datatype top = TCP 

datatype 'a safe_sock = W of Word32.word 
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where user-defined restrictions are reflected in the constrained types of values and 
functions, underlies many interesting uses of type systems. It has been used to de- 
rive early implementations of extensible records (Wand, 1987; Rcmy, 1989; Burton, 
1990), to provide a safe and flexible interface to the Network Socket API (Reppy, 
1996), to interface to COM components (Finne et at, 1999), to type embedded 
compiler expressions (Leijen & Meijer, 1999; Elliott et ai, 2000), to record sets of 
effects in type-and-effect type systems (Pcssaux & Leroy, 1999), to embed a repre- 
sentation of the C type system in SML (Blume, 2001), and to encode data structure 
invariants (Fluet & Pucella, 2005). 

This paper makes a number of contributions to the extant literature on phantom 
types. The first contribution is to describe a general procedure for applying the 
phantom-types technique to subtyping, generalizing all the known uses of phantom 
types of which we are aware. This procedure relies on an appropriate encoding of 
the subtyping hierarchy. We study different classes of encodings for different kinds 
of hierarchies. Next, we formalize this use of phantom types and prove its correct- 
ness. We present a type-preserving translation from a calculus with subtyping to 
a calculus with let-bounded polymorphism, using the procedure described earlier. 
The kind of subtyping that can be captured turns out to be an interesting variant of 
bounded polymorphism (Cardelli et al., 1994), with a very restricted subsumption 
rule. 

This paper is structured as follows. In the next section, we describe a simple 
recipe for deriving an interface enforcing a given subtyping hierarchy. The interface 
is parameterized by an encoding, via phantom types, of the subtyping hierarchy. In 
Section 3, we examine different encodings for hierarchies. We also address the issue 
of extensibility of the encodings. In Section 4, we extend the recipe to capture a 
limited form of bounded polymorphism. In Section 5, we formally define the kind 
of subtyping captured by our encodings by giving a simple calculus with subtyping 
and showing that our encodings provide a type-preserving translation to a variant 
of the Damas-Milner calculus, embodying the essence of the SML type system. 
We conclude with some problems inherent to the approach and a consideration of 
future work. The formal details of the calculi we introduce in Section 5 as well as 
the proofs of our results can be found in the appendices. 



The examples in the introduction has the following features: an underlying base 
type of values (the original type atom and the type Word32.word for sockets), a 
set of primitive operations on values of the base type, and sorts of this base type 
that correspond to the sensible domains of the operations. The sorts of the base 
type form a hierarchy capturing the subtyping inherent in the sorts. The subtyping 
hierarchy corresponding to the atom example is as follows: 



2 From Subtyping to Polymorphism 



atom 




int 



boot. 
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(We assume there is a sort corresponding to the base type as a whole, always the 
top of the hierarchy, capturing the intuition that every sort is a subtype of the base 
type.) The subtyping hierarchy is modeled by assigning a type to every sort in the 
hierarchy. For instance, integer atoms with sort int are encoded by the SML type 
int safe_atom. The appropriate use of polymorphic type variables in the type 
of an operation indicates the maximal type in the domain of the operation. For 
instance, the operation toString has the conceptual type atom -> string which 
is encoded by the SML type 'a safe.atom -> string. The key observation is the 
use of type unification to enforce the subtyping hierarchy: an int saf e_atom can 
be passed to a function expecting an 'a saf e_atom, because these types unify. 

In this section, we show by means of an example, given a base type r^, a set of 
sorts of Tf, (forming a hierarchy), and operations expressed in terms of the sorts of 
Tft, how to derive: 

• a safe SML signature which uses phantom types to encode the subtyping 
between sorts, and 

• a safe implementation from the unsafe implementation. 

By safety here, wc mean that the interface guarantees that no primitive operation 
is ever supplied a value outside its domain; we return to this point in Section 2.2, 
and make this guarantee precise in Section 5. 

All values share the same underlying representation (the base type Tb) and each 
operation has a single implementation that acts on this underlying representation. 
The imposed subtyping captures restrictions that arise because of some external 
knowledge about the semantics of the operations; intuitively, it captures a "real" 
subtyping relationship that is not exposed by the representation of the abstract 
type. 

We must emphasize at this point that we are concerned only with subtyping of 
values passed to primitive operations, where the values are base values as opposed 
to higher-order values such as functions. Therefore, we are interesting in first-order 
subtyping only. Of course, since SML is higher-order, we must say something about 
the subtyping on higher-order values induced by the subtyping on the base values. 
The subtyping relation on higher-order values will turn out to be severely restricted. 
We return to this point in Section 4. 

2.1 The Safe Interface 

We first consider deriving the safe interface. The new interface defines a type ' a r 
corresponding to the base type r{,. The instantiations of the type variable 'a will be 
used to encode sort information. We require an encoding (a) of each sort a in the 
hierarchy; this encoding should yield a type in the underlying SML type system, 
with the property that (ui) unifies with (0-2) if and only if ai is a subtype of (72 
in the hierarchy. An obvious issue is that we want to use unification (a symmetric 
relation) to capture subtyping (an asymmetric relation). The simplest approach is 
to use two encodings {■)c and {■)a defined over all the sorts in the hierarchy. A 
value of sort a will be assigned a type {a)c t. We call {a)c the concrete encoding 
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of CT, and we assume that it uses only ground types (i.e., no type variables). In order 
to restrict the domain of an operation to the set of values that are subtypes of a 
sort (T, we use {a) a, the abstract encoding of a. In order for the underlying type 
system to enforce the subtyping hierarchy, wc require the encodings {•)c and {•)a 
to be respectful by satisfying the following property: 

for all ui and (72, (ci)c matches {02) a iff fi < cr2 . 

For example, the encodings used in the introduction are respectful: 

{atom) A — 'a {atom)c — unit 

{int)A — int {int)c — int 

{hoot) A — bool {boot)c — bool. 

The utility of the phantom-types technique relies on being able to find respectful 
encodings for subtyping hierarchies of interest. 

To allow for matching, the abstract encoding will introduce free type variables. 
Since, in a Hindley-Milner type system, a type cannot contain free type variables, 
the abstract encoding will be part of the larger type scheme of some polymorphic 
function operating on values of appropriate sorts. This leads to some restrictions 
on when we should constrain values by concrete or abstract encodings. For the time 
being, we will restrict ourselves to using concrete encodings in all covariant type 
positions and using abstract encodings in most contravariant type positions. It is 
fairly easy to see that if we do not impose this restriction, then we can assign type 
to functions that break the desired subtyping invariants. For example, suppose we 
added the following function to our collection of "safe" atom operations: 

fun randAtom ():'a safe_atoin = 
(case randO 

of => W (B (false)) 
I 1 => W (B (true)) 
I i => W (I (i))). 

Note that randAtom is assigned the type unit -> 'a safe_atoin, which appears 

to be consistent with the fact that randAtom returns some subtype of the sort 
atom. However, the expression conj (remdAtom () , reindAtom ()) is considered 
well-typed, but its evaluation may raise a run-time exception. Intuitively, the issue 
with returning a value constrained by an abstract encoding is that we are trying to 
impose a restriction on the behavior of the function based on the types of future uses 
of the returned value; such type-directed behavior is not supported in a language 
like SML. We will return to this issue in Section 4. Another consequence of having 
the abstract encoding be part of a larger type scheme that binds the free variables 
in prenex position is that the subtyping is resolved not at the point of function 
application, but rather at the point of type application, when the type variables are 
instantiated. We postpone a discussion of this important point to Section 4, where 
wc extend our recipe to account for a form of bounded polymorphism. 

Consider again the atom example from the introduction. Assume we have encod- 
ings {■)c and {■)a for the hierarchy and a structure Atom implementing the "unsafe" 
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signature ATOM = sig 
type atom 

val mkint : int -> atom 
val mkBool: bool -> atom 
val toString: atom -> string 
val double: atom -> atom 
val conj : atom * atom -> atom 
end 

(a) Unsafe interface 



signature SAFE_ATOM = sig 
type 'a safe_atom 

val mkInt : int -> {int)c: safe_atom 
val mkBool: bool -> {hool)c safe_atom 
val toString: {atom) a safe_atom -> string 
val double: {int) a safe_atom -> {int) c safe_atom 
val conj: {bool) a safe_atom * {bool) a safe_atom 
-> {hool)c safe_atom 

end 

(b) Safe interface 



Fig. 3. Interfaces for atoms 



structure SafeAtoml :> SAFE_ATaM = struct 

type 'a safe_atom = Atom. atom 
val mkInt = Atom.mkint 
val mkBool = Atom. mkBool 
val toString = Atom . toString 
val double = Atom. double 
val conj = Atom. conj 
end 

(a) Opaque signature 



structure Saf eAtom2 : SAFE_ATDM = struct 

datatype 'a safe_atom = W of Atom. atom 
fun int (i) = W (Atom.mkint (i)) 
fun bool (b) = W (Atom. mkBool (b)) 
fun toString (W v) = Atom . toString (v) 
fun double (W v) = W (Atom. double (v) ) 
fun conj (W bl, W b2) = ¥ (Atom. conj (bl,b2)) 
end 

(b) Datatype declaration 



Fig. 4. Two implementations of the safe interface for atoms 



operations, with the signature ATOM given in Figure 3(a). Deriving an interface using 
the recipe above, we get the safe signature given in Figure 3(b). ^ 



2.2 The Safe Implementation 

We must now derive an implementation corresponding to the safe signature. We 
need a type ' a r isomorphic to Tb such that the type system considers n and T2 
equivalent when n r and T2 t are equivalent. We can then constrain the types of 
values and operations using {a)c t and {(t)a t, as indicated above. There are two 
ways of enforcing this equivalence in SML: 

1. Wc can use an abstract type at the module system level, as shown in Fig- 
ure 4(a). The use of an opaque signature is critical to get the required behavior 
in terms of type equivalence. The advantage of this method is that there is 
no overhead. 

^ The signature wc use is fairly minimal. There axe other functions that would be useful, and 
that arc still safe with respect to our definition of safety that we use in Section 5. For instance, 

consider the following function: 

fun f (b) = if b then Saf eAtom.mklnt (3) else Saf eAtom. mkBool (false). 

This function does not type-check, since Saf eAtom.mklnt (3) has type int safe_atom while 
Saf eAtom. mkBool (false) has type bool safe.atom (assuming the concrete and abstract en- 
codings defined earlier). What one wants here are coercion functions, that taJje values of sort 
bool or sort int and coerce them to the sort atom. This corresponding to adding a function 
coerceToAtom of type 'a safe.atom -> unit safe.atom to the safe interface for atoms; the im- 
plementation of this function is simply the identity function. We will not use coercion functions 
in this paper, but they can be added without difficulty. 
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2. We can wrap the base type tjj using a datatype declaration 

datatype 'a r = W of Tfe. 

The type ' a r behaves as required, because the datatype declaration defines 
a generative type operator. However, we must explicitly convert values of 
the base type to and from ' a r to witness the isomorphism. This yields the 
implementation given in Figure 4(b). 

Note that the equivalence requirement precludes the use of type abbreviations of 
the form type 'a r = not restricted by an opaque signature, which generally 
define constant type functions. Moreover, in a language such as Haskell which does 
not provide abstract types at the module level, the second approach is the only one 
available. Therefore, for the sake of generality, we use the second approach through- 
out this paper, with the understanding that our discussion can be straightforwardly 
adapted to the first approach. 

We should stress that the safe interface must ensure that the type 'a r is 
abstract — either through the use of opaque signature matching, or by hiding the 
value constructors of the type. Otherwise, it may be possible to create values that 
do not respect the subtyping invariants enforced by the encodings. For example, 
exposing the wrapper constructor allows a client to write the following, which type- 
checks, but violates the implicit subtyping: 

val bogus = (W (Atom.mklnt 5)) : bool safe_atoin 

val bad = conj (bogus, bogus). 
The evaluation of conj (bogus, bogus) will raise a run- time exception. This ex- 
ample demonstrates the subtle difference between the guarantee made by the SML 
type-system and the guarantee made by a library employing the phantom-types 
technique. While the former ensures that "a well-typed program won't go wrong," 
the latter ensures that "a well-typed client won't go wrong, provided the library is 
correctly implemented." The purpose of this section has been to better character- 
ize what it means for a library to be "correctly implemented," while Section 5 will 
make this characterization precise. 

We now have a way to derive a safe interface and implementation, by adding 
type information to a generic, unsafe implementation. In the next section, we show 
how to construct respectful encodings {■)c and {■)a by taking advantage of the 
structure of the subtyping hierarchy. 

3 Encoding Hierarchies 

The framework presented in the previous section relies on having concrete and ab- 
stract encodings of the sorts in the subtyping hierarchy with the property that 
unification of the results of the encoding respects the subtyping relation. In this 
section, we describe how such encodings can be obtained. Different encodings are 
appropriate, depending on the characteristics of the subtyping hierarchy being en- 
coded. We assume, for the purpose of this paper, that subtyping hierarchies are 
at least join-semilattices. These encodings assume that the subtyping relation is 
completely known a priori. We address the question of extensibility in Section 3.5. 
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3.1 Tree Hierarchies 

For the time being, we restrict ourselves to finite subtyping hierarchies. The simplest 
case to handle is a tree hierarchy. Since this is the type of hierarchy that occurs 
in both examples discussed in the introduction (and, in fact, in all the examples 
we found in the literature on encoding subtyping hierarchies in a polymorphic type 
system), this encoding should be clear. The idea is to assign a type constructor to 
every subtype of a subtyping hierarchy. Assume we have an encoding {■)]sf assigning 
a distinct (syntactic) name to each entry in a subtyping hierarchy (S, <). Hence, 
for each u € S, we define: 



datatype 'a {a)N = Irrelevant_(cr)jv 



(The name of the data constructor is completely irrelevant, as we will never con- 
struct values of this type. It is required because SML does not allow the definition 
of a datatype with no constructors.) 

For example, consider the following subtyping hierarchy (which is essentially the 
one used in the Sockets API described by Reppy (1996)): 




We first define type constructors for every element of the hierarchy. We assume a 
reasonable name encoding {■)n, such as (A)jv = A, (i?)jv = B, etc. Hence, we have 

datatype 'a A = Irrelevant_A 
datatype ' a B = Irrelevant _B 

and likewise for the other elements. The concrete encoding for an element of the 
hierarchy represents the path from the top of the hierarchy to the element itself. 
Hence, 

{A)c = unit A 
{B)c = (unit B) A 
{C)c = (unit C) A 
{D)c = ((unit D) C) A 
{E)c = ((unit E) C) A. 

For the corresponding abstract encoding to be respectful, we require the abstract 
encoding of cr to unify with the concrete encoding of all the subtypes of cr. In other 
words, we require the abstract encoding to represent the prefix of the path leading 
to the element a in the hierarchy. We use a type variable to unify with any part of 
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the path after the prefix we want to represent. Hence, 

{A) A = 'ai A 

{B)a = ('a2 B) A 

{C)a = ('as C) A 

{D)a = (('a4 D) C) A 

{E)a = (('as E) C) A. 

We can then verify, for example, that the concrete encoding of D unifies with the 
abstract encoding of C, as required. 

Note that {■)a requires every type variable 'a^ to be a fresh variable, unique in 
its context. This ensures that we do not inadvertently refer to any type variable 
bound in the context where we are introducing the abstractly encoded type. The 
following example illustrates the potential problem. Let (S, <) be the subtyping 
hierarchy given above, over some underlying base type ti,. Suppose we wish to 
encode an operation of type A * A -> int with the understanding that a (different) 
subtype of A may be passed for each of the arguments. The encoded type of the 
operation becomes (A) a t * (A) a t -> int (where 'a r is the wrapped type of Tb 
values) which should translate to ('a A) r * ('b A) t -> int. If we are not careful 
in choosing fresh type variables, we could generate the following type ('a A) r * 
('a A) T -> int, corresponding to a function that requires two arguments of the 
same type, which is not the intended meaning. (The handling of introduced type 
variables is somewhat delicate; we address the issue in more detail in Section 4.) 

It should be clear how to generalize the above discussion to concrete and abstract 
encodings for arbitrary finite tree hierarchies. Let Ts correspond to the root of the 
finite tree hierarchy. Define an auxiliary encoding {■)x which can be used to con- 
struct chains of type constructors. The encoding {(t)x returns a function expecting 
the type to "attach" at the end of the chain 

(Ts)x (i) = t (Ts)jv 
{a)x (t) = (crp,,„t)x (t {<j)n) where (Tpa,ent is the parent of a. 

Thus, in the example above, we have: 

{A)x (t) ^ t A 

{B)x (t) - (tB) A 

{C)x (t) = (t C) A 

{D)x it) = ((t D) C) A 

{E)x (t) = ((i E) C) A. 

Using this auxiliary encoding, we can define the concrete and abstract encodings 
by supplying the appropriate type: 

(cr)c = {(t)x (unit) 

{cr)A — ('a) where ' a is fresh. 
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3.2 Finite Power set Lattices 

Not every subtyping hierarchy of interest is a tree. More general hierarchies can 
be used to model multiple interface inheritance in an object-oriented setting. Let 
us now examine more general subtyping hierarchies. We first consider a particular 
lattice that will be useful in our development. Recall that a lattice is a hierarchy 
where every set of elements has both a least upper bound and a greatest lower 
bound. Given a finite set S, we let the powerset lattice of S be the lattice of all 
subsets of S, ordered by inclusion, written {p{S), C). We now exhibit an encoding 
of powerset lattices. 

Let n be the cardinality of S and assume an ordering si, . . . , s„ on the elements of 
S. We encode subset X of 5 as an n-tuple type, where the i^^ entry expresses that 
Si e X or Si ^ X. First, we introduce a datatype that roughly acts as a Boolean 
value at the level of types: 



datatype 'a z = Irrelevant_z. 

The encoding of an arbitrary subset of S is given by: 

{X)c — ti * . . . * tn where ti = 



unit if Si G X 
unit z otherwise 



{X)a = ti * . . . * tn where ti 



' aj if Si G X 
'ai z otherwise. 



Note that {■)a requires every type variable 'ai to be a fresh type variable, unique 
in its context. This ensures that we do not inadvertently refer to any type variable 
bound in the context where we are introducing the abstractly encoded type. 

As an example, consider the powerset lattice of {1,2,3,4}, which encodes into 
a four-tuple. We can verify, for example, that the concrete encoding for {2}, 
namely (unit z * unit * unit z * unit z) , unifies with the abstract encoding 
for {1, 2}, namely ( 'ai * 'a2 * 'as z * 'a4 z) . On the other hand, the concrete 
encoding of {1,2}, namely (unit * unit * unit z * unit z) , does not unify 
with the abstract encoding of {2,3}, namely Cai z * 'a.2 * 'as * 'a4 z). 



3.3 Embeddings 

The main reason we introduced powerset lattices is the fact that any finite hierarchy 
can be embedded in the powerset lattice of a set S. It is a simple matter, given 
a hierarchy E' embedded in a hierarchy S, to derive an encoding for S' given an 
encoding for S. Let inj{-) be the injection from E' to E witnessing the embedding 
and let {■)cs ^^'^ {')as be the encodings for the hierarchy E. Deriving an encoding 
for E' simply involves defining (a-)cj,, — {inj{a))c^ and {o-)a^, — {inj{a))As- It 
is straightforward to verify that if {■)cs ^^'^ {')as respectful encodings, so are 
(•)cj,, and {■)aj,,- By the result above, this allows us to derive an encoding for an 
arbitrary finite hierarchy. 

To give an example of embedding, consider the following subtyping hierarchy to 
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be encoded: 



A 



B 




D 



E. 




F 



Notice that this hierarchy can be embedded into the powerset lattice of {1, 2, 3, 4}, 
via the injection function sending A to {1,2,3,4}, B to {1,2,3}, C to {2,3,4}, D 
to {2,3}, E to {3,4}, and F to {2}. 



We have presented recipes for obtaining respectful encodings, depending on the 
characteristics of the subtyping hierarchy at hand. It should be clear that there are 
more general hierarchies than the ones presented here that can still be encoded, 
although the encodings quickly become complicated and ad hoc. It would be an 
interesting project to study in depth the theory of hierarchies encoding that seems 
to be lurking here. As an example, let us examine an encoding that generalizes the 
finite powerset lattice encoding to the (countably) infinite case, but where only the 
finite subsets of a countably infinite set arc encoded. Therefore, this encoding is 
only useful when a program manipulates only values with sorts corresponding to 
finite subsets in the hierarchy. While ad hoc, this example is interesting enough to 
warrant a discussion. 

Technically, the encoding is in the spirit of the finite powerset encoding. Let 5* 
be a countably infinite set, and assume an ordering si, S2, . . . of the elements of S. 
As in the finite case, we define a datatype 



The encoding is given for finite subsets of S by the following pair of encodings: 



3.4 Other Encodings 



datatype 'a z = Irrelevant _z . 



{X)c 



= {h*{t2*{h* ...*{tn* 'Si)...))) 



y unit z otherwise 
and n is the least index such that X C {si, . . . 
= (ii * (^2 * (^3 * ■ • ■ * {tn * unit), ...))) 




Sn} 



{X)a 




and n is the least index such that X C {si, . . . 



Sn}. 



(As usual, with the restriction that the type variables 'ai, . . . , 'a„ are fresh.) One 
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can verify that this is indeed a respectful encoding of the finite elements of the 
infinite lattice. 

Note that this use of a free type variable to be "polymorphic in the rest of the 
encoded value" is strongly reminiscent of the notion of a row variable, as origi- 
nally used by Wand (1987) to type extensible records, and further developed by 
Remy (1989). The technique was used by Burton (1990) to encode extensible records 
directly in a polymorphic type system. Recently, the same technique was used to 
represents sets of effects in type-and-effect systems (Pessaux & Leroy, 1999). 

We have not focussed on the complexity or space-efficiency of the encodings. 
We have emphasized simplicity and uniformity of the encodings, at the expense of 
succinctness. For instance, deriving an encoding for a finite hierarchy by embedding 
it in a powerset lattice can lead to large encodings even when simpler encodings 
exist. Consider the following subtyping hierarchy: 



A 




H. 



The smallest powerset lattice in which this hierarchy can be embedded is the pow- 
erset lattice of a 6-element set; therefore, the encoding will require 6-tuples. On 
the other hand, it is not hard to verify that the following encoding respects the 
subtyping induced by this hierarchy. As before, we define a datatype 

datatype ' a z = Irrelevant_z . 

Consider the following encoding: 



{A)c 




(unit * unit) 


{B)c 




(unit z * unit) 


{C)c 


A^ 


(unit * unit z) 


{D)c 


A_ 


((unit z) z * unit z) 


{E)c 


_A 


(unit z * (unit z) z) 


{F)c 


A^ 


(((unit z) z) z * (unit z) z) 


{G)c 


A_ 


((unit z) z * ((unit z) z) z) 


{H)c 


A^ 


(((unit z) z) z * ((unit z) z) z) 
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The abstract encoding is obtained by replacing every unit by a type variable ' a, 
taken fresh, as usual. 

It is possible to generate encodings for finite hierarchies that are in general more 
efficient than the encodings derived from the powcrsct lattice cmbeddings. One 
such encoding, which we now describe, uses a tuple approach just like the powerset 
lattice encoding. This encoding yields tuples whose size correspond to the width 
of the subtyping hierarchy being encoded, rather than the typically larger size of 
the smallest set in whose powerset lattice the hierarchy can be embedded. (The 
efficient encoding for the previous subtyping hierarchy is an instance of such a 
width encoding.) 

Let (S, <) be a hierarchy wc wish to encode. The width of S is the maximal size 
of sets of incomparable elements. Formally, 

w(S) =max{|X| | X C E, Vx, y G E, (x ^ y A y^x)]. 

The following proposition allows us to derive an encoding based on the width of 

the hierarchy. 

Proposition 3.1 

Let E be a finite hierarchy, and w be the width of E. There exists a function 
Z : E — > N"" such that a; < y if and only if for i = 1, . . . , w, l{x){i) > l{y){i). 

Proof 

Choose S = {s\, . . . , Sw} a subset of E such that 5 is a set of mutually incomparable 

elements of size w. Wc iterativcly define a function Z' : E — »■ Q. We initially set 
^'(Te) — (0, . . . , 0), and for every Si in the set 5, 



l'{si) = (ai, . . . , a^) where = | 2 



otherwise. 



Iteratively, for all elements x £ E not assigned a value by Z', define the sets 
= {y € E I y is assigned a value by I' and y > x} 

and 

.T^ = {j/ G E I y is assigned a value by /' and y < x}. 

It is easy to verify that either x> fl 5* 7^ or x< fl 5* 7^ 0, but not both (otherwise, 
there exists y^ G 5 and y^ G 5 such that y^ > x > y^, and hence y^ > y^, con- 
tradicting the mutual incomparability of elements of S). Define l'{x) = (xi, . . . , x„), 
where 

A minj/gx< {l'{y)(i)} + max^ga;> {l'{y) (»)} 

We can now define the function Z : E — *• by simply rescaling the result of the 
function V . Let R be the sequence of all the rational numbers that appear in some 
tuple position in the result l'{x) for some x G E, ordered by the standard order 

on Q. For r E R, let i(r) be the index of the rational number r in R. Define the 
function I by l{x) = {i{l' {x){l)), . . . , i{l' {x){w))). It is straightforward to verify that 
the property in the proposition holds for this function. □ 
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We can use Proposition 3.1 to encode elements of a finite hierarcliy S. Define a 
datatype 

datatype 'a z = Irrelevant_z . 

(As usual, the data constructor name is irrelevant). We encode an element into a 
tuple of size w, the width of S. Assume we have a labeling of the elements of S by 
a function / as given by Proposition 3.1. Essentially, I will indicate the nesting of 
the above type constructor in the encoding. Formally, 

{X)c = (... (unit z). . .z) *...*(... (unit z). . .z) 
^ ^ ^ ^ 

/(x)(l) l(x)(w) 

{X)a = (... Cai z)...z) *...*(... Ca^ z)...z). 

Kx)(l) l{x){w) 

(As usual, each 'a^ in {■)a is fresh.) 

The fact that there are different encodings for the same hierarchy raises an obvi- 
ous question: how do we determine the best encoding to use for a given hierarchy 
in a given situation? There are interesting problems here, for instance, lower and 
upper bounds on optimal encodings for hierarchies, as well as measurement metrics 
for comparing different encodings. We know of no work directly addressing these 
issues. 

3.5 Extensibility 

One aspect of encodings we have not yet discussed is that of extensibility. Roughly 
speaking, extensibility refers to the possibility of adding new elements to the sub- 
typing hierarchy after a program has already been written. One would like to avoid 
having to rewrite the whole program taking the new subtyping hierarchy into ac- 
count. This is especially important in the design of libraries, where the user may 
need to extend the kind of data that the library handles, without changing the 
provided interface. For example, we can easily adapt the subtyping hierarchy of the 
atom example to accommodate strings by extending the SAFE_ATOM signature with 

val mkString: string -> (str)c ScLfe_atom 

val concat: {str)A safe.atom * {str}A safe.atom -> {str)c safe_atom 
and taking 

{str)A — string {str)c — string. 
Note that while the implementations of the Atom and Saf eAtom structures require 
changes, no existing client of the SAFEJVTOM signature requires any changes. In this 
section, we examine the extensibility of the encodings we have presented. 

Looking at the encodings of Section 3, it should be clear that the only immediately 
extensible encodings are the tree encodings in Section 3.1. In such a case, adding 
a new sort cr„ew as an immediate subtype of a given sort C7pa,re„t in the tree simply 
requires the definition of a new datatype: 

datatype 'a (o-„e„)jv = Irrelevant_(c7„ew)Ar • 
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We assume a naming function (•)jv extended to include a„ew One can check that 
the abstract and concrete encodings of the original elements of the hierarchy are not 
changed by the extension — since the encoding relies on the path to the elements. 
The concrete and abstract encodings of the new subtype (T„ew is just the path to 
c„ew) as expected. 

The powerset lattice encodings and their embeddings are not so clearly extensible. 
Indeed, in general, it does not seem possible to arbitrarily extend an encoding of 
a subtyping hierarchy that contains "join elements" (that is, a sort which is a 
subtype of at least two otherwise unrelated sorts, related to multiple inheritance in 
object-oriented programming). However, as long as the extension takes the form of 
adding new sub-sorts to a single sort in the hierarchy, it is possible to extend any 
subtyping hierarchy in a way that does not invalidate the original encoding of the 
hierarchy. As an illustration, consider again the simplest case, where we want to add 
a new sort cr„ew to an existing hierarchy, where cr„e„ is an immediate subtype of the 
sort (Tp„„„, . Assume that the existing hierarchy is encoded using the finite powerset 
encoding of Section 3.2. Observe that in the lattice encodings, the encoding of a 
sort cr corresponding to subset {si^, . . . , Sj„} contains a unit in the tuple positions 
corresponding to Si^ through Si^^ , and unit z in the other positions. To encode the 
new sort iT„ew) we can simply create a new type 



datatype 'a (a-„ew)jv = Irrelevant_(£7„ew) 



N 



as in the case of tree encodings, and, for the concrete encoding, replace every unit 

in the concrete encoding of CTparom by unit ((T,„,„)jv- For the abstract encoding of 
Cnew) we replace every unit in the concrete encoding by a (fresh) type variable. 
One can verify that indeed the resulting encoding is respectful of the subtyping 
hierarchy with the additional sort (T„ew- 

We can easily generalize this procedure of adding a new sort to an existing hier- 
archy encoded using a powerset lattice encoding to the case where we want to add 
a whole hierarchy as subtypes of a single sort in an existing hierarchy. Here is an 
outline of the general approach, of which the above is a special case. Let S be a 
powerset lattice over a set S of cardinality n, and let CTp^^rent be an element of E we 
want to extend by another hierarchy S„e„; that is, all elements of S„ew are subtypes 
of cTparent aud lucomparablc to other elements of S. Assume that S is encoded via a 
lattice embedding encoding {■)c, {■)a, and that S„„„ is encoded via some encoding 
(■)c„ewi (')A„ew- We can extend the encoding for S over the elements a' € 



W)c — tl * . . . * tn where ti 
{o'')a — tl * . . . * tn where ti 



unit z otherwise 

(l^OAnew if Si e O-parent 

'a,: z otherwise. 



(As usual, each ' a^ in (•)^ , including the type variables in (a'')A„e„ , is fresh.) Again, 

such an encoding is easily seen as being respectful of the extended subtyping hi- 
erarchy. The above scheme generalizes in a straightforward way to encodings via 
lattice embeddings and to the countable lattice encoding of Section 3.4. 
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As an example, we extend the hierarchy of Section 3.3 as follows: 



A 




B' C 




D' E' F'. 

The complete concrete encoding is given by: 

(^')c„cw - (unit * unit) 
{B')c^,^ = (unit * unit z) 
(C'')c„e„ - (unit z * unit) 
(-D'>C„ew - (unit * (unit z) z) 
(£;')c„e„ = (unit z * unit z) 
(F')c„e„ = ((unit z) z * unit) 



and 

{A)c — (unit * unit * unit * unit) 
{B)c — (unit * unit * unit * unit z) 
(C')c — (unit z * unit * unit * unit) 
{D)c — (unit z * unit * unit * unit z) 
{E)c — (unit z * unit z * unit * unit) 
{F)c — (unit z * unit * unit z * unit z) 

{A')c (unit z * (unit * unit) * (unit * unit) * unit z) 

{B')c = (unit z * (unit * unit z) * (unit * unit z) * unit z) 

{C')c — (unit z * (unit z * unit) * (unit z * unit) * unit z) 

{D')c — (unit z * (unit * (unit z) z) * (unit * (unit z) z) * unit 

{E')c — (unit z * (unit z * unit z) * (unit z * unit z) * unit z) 
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{F')c = (unit z * ((unit z) z * unit) * ((unit z) z * unit) * unit z). 

The abstract encoding is obtained by replacing every unit by a type variable ' a, 
taken fresh, as usual. 

The interesting thing to notice about the above development is that although 

extensions are restricted to a single sort (i.e., we can only subtype one given sort), 
the extension can itself be an arbitrary lattice. As we already pointed out, it does 
not seem possible to describe a general extensible encoding that supports subtyping 
two different sorts at the same time (multiple inheritance). In other words, to adopt 
an object-oriented perspective, we cannot multiply-inherit from multiple sorts but 
we can single-inherit into an arbitrary lattice, which can use multiple inheritance 
locally. 

4 Encoding a More General Form of Subtyping 

As mentioned in Section 3, the handling of type variables is somewhat delicate. In 

this section, we revisit this issue. We show, by approaching the problem from a 
different perspective, how we can encode using phantom types a more general form 
of subtyping than simply subtyping at function arguments. We believe that this is 
the right setting to understand the ad-hoc restrictions given previously. 

If we allow common type variables to be used across abstract encodings, then 
we can capture a form of bounded polymorphism as in F<: (Cardelli et at, 1994). 
Bounded polymorphism is a typing discipline which extends both parametric poly- 
morphism and subtyping. From parametric polymorphism, it borrows type variables 
and universal quantification; from subtyping, it allows one to set bounds on quan- 
tified type variables. For example, one can guarantee that the argument and return 
types of a function are the same and a subtype of a, as in Va<:cr(a — > a).^ Simi- 
larly, one can guarantee that two arguments have the same type that is a subtype 
of (7, as in Va<:a(a x a ^ u). Notice that neither function can be written in a 
language that supports only subtyping. In short, bounded polymorphism lets us be 
more precise when specifying subtyping occurring in functions. 

The recipe we gave in Section 2 shows that we can captiire siibtyping using 
parametric polymorphism and restrictions on type equivalence. It turns out that 
we can capture a form of bounded polymorphism by adapting this procedure. As an 
example, consider the type V/3<:cri(/3 x (T2 ^ /?)• Let the "safe" interface use types 
of the form a r. Since /3 stands for a subtype of cti, we let (pjs = {(Ti)a, the abstract 
encoding of the bound. We then translate the type as we did in Section 2, but 
replace occurrences of the type variable /3 by (j)/) instead of applying {■)a repeatedly. 
This lets us share the type variables introduced by {(Ti)a - Hence, we get the type 
(j)/} T X {(12) A T ^ ipfj T. This procedure in fact generalizes that of Section 2: we can 
convert all the subtyping into bounded polymorphism. More precisely, if a function 
expects an argument of a sort that is a subtype of o", we can introduce a fresh type 
variable for that argument and bind it by a. For example, the type above can be 

^ In this section, we freely use a F<:-lil£e notation for expressions. 
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rewritten as V/3<:cri(V7<:cr2(/3 x 7 — > /?)), and encoded as (p/j t x (p^ t ^ (j)i3 
where (p/s = (cri)A and 0^ = (ct2)a- 

As one might expect, this technique does not generaUze to full F^-,. For example, it 
is not clear how to encode types using bounded polymorphism where the bound on a 
type variable uses a type variable, such as a function f with type Vq;<:(t(V/3<:q;(q; x 
(3 a)). Encoding this type as (pa t x (f)p t (pa r, where (pa — {<j)a and 
(p/s = {a) A, fails, because we have no definition of (a) a- Essentially, we need a 
different encoding of /3 for each instantiation of a at each application of f , something 
that cannot be accommodated by a single encoding of the type at the definition of 
f. 

However, the most important restriction on the kind of bounded polymorphism 
that can be handled in a straightforward way is due to the fact that we are capturing 
this form of subtyping using SML, which uses prenex parametric polymorphism. 
This means, for instance, that we cannot encode first-class polymorphism, such as 
a function g with type \fa<:ai{a —>■ (V/3<:cr2(/3 — > /?)))• Applying the technique 
yields a type (pa t ^ (pjs t ^ (pp t where (pa and (pp contain free type variables. 
A Hindley-Milner style type system requires quantification over these variables 
in prenex position, which doesn't match the intuition of the original type. Thus, 
because we are translating into a language with prenex polymorphism, it seems we 
can only capture bounded polymorphism that is itself in prenex form. 

One consequence of being restricted to prenex bounded polymorphism is that we 
cannot account for the general subsumption rule found in F<:. Instead, we require 
all subtyping to occur at type application. This is why we can convert all subtyping 
into bounded polymorphism, as we did above. By introducing type variables for each 
argument, we move the resolution of the subtyping to the point of type application 
(when we instantiate the type variables) . The following example may illustrate this 
point. In F<: with first-class polymorphism, we can write a function appl with type 
(Vq!<:(Ti(q; (J2)) ^ (72 X C72 that applies a function to two values, vl of type ai 
and v2 of type 0^2 < ui, using an SML-like syntax that should be self-explanatory: 



local 

val vl : CTi = . . . 
val v2 : 02 = ■ ■ ■ 

in 

fun appl (f : Va < (Ti(a — > (72)) : (72 x (72 
(f [<Ti] vl, f [(T2] v2) 

end. 



This definition of appl type-checks when we apply the argument function to a\ 
and then to vl and we apply the argument function to a2 (using subsumption at 

type application) and then to v2. But, as we argued above, we cannot encode first- 
class polymorphism. An alternative version, app2, can be written in F<: with type 

(CTI — > 0-2) — > 0-2 X (72: 
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local 

val vl : (Ti = . . . 
val v2 : (T2 = . . . 

in 

fun app2 (f : {a\ — *■ (72)) : (72 x ^2 = 
(f vl, f (v2 : CTi)) 

end. 

This definition of app2 type-checks when we apply the argument function to vl and 
we apply the argument function to v2 (using subsumption on v2, coercing from cr2 
to (Ti). Yet, we cannot give any reasonable encoding of app2 into SML, because 
it would require applying the argument function to the encoding of vl. with type 
(ci)c ''') and to the encoding of v2, with type {02)0 t; that is, it would require 
applying an argument function at two different types. As hinted above, this is a 
consequence of the lack of first-class polymorphism in the SML type system; the 
argument function cannot be polymorphic. 

These two restrictions impose one final restriction on the kind of subtyping we 
can encode. Consider a higher-order function h with type Va<:((Ti <T2){cx — > (T2). 
What are the possible encodings of the bound ai a2 that allow subtyping? 
Clearly encoding the bound as {<Ji)c t ^ {o'2)c t docs not allow any subtyping. 
Encoding the bound as (cri)yi t {(72) A t or (cti)^ t (0-2 }c t leads to an 
unsound system. (Consider applying the argument function to a value of type cto > 
(Ti, which would type-check in the encoding, because (o'o}c unifies with {(Ti)a by 
the definition of a respectful encoding.) However, we can soundly encode the bound 
as (cti)c t — * (f2)A T. This corresponds to a subtyping rule on functional types 
that asserts n ^ r2 < n ^ T2 if and only if T2 < T2. This is the main reason why 
we focus on first-order subtyping in this paper. 

Despite these restrictions, the phantom- types technique is still a viable method 
for encoding subtyping in a language like SML. All of the examples of phantom 
types found in the literature satisfy these restrictions. In practice, one rarely needs 
first-class polymorphism or complicated dependencies between the subtypes of func- 
tion arguments, particularly when implementing a safe interface to existing library 
functions. 

5 A Formalization 

As the previous section illustrates, there are subtle issues regarding the kind of 
subtyping that can be captured using phantom types. In this section, we clarify the 
picture by exhibiting a typed calculus with a suitable notion of subtyping that can 
be faithfully translated into a language such as SML, via a phantom types encod- 
ing. The idea is simple: to see if an interface can be implemented using phantom 
types, first express the interface in this calculus in such a way that the program 
type-checks. If it is possible to do so, our results show that a translation using 
phantom types exists. The target of the translation is a calculus embodying the 
essence of SML, essentially the calculus of Damas and Milner (1982), a predicative 
polymorphic lambda calculus. 
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5.1 The Source Calculus 



Our source calculus, A™, is a variant of the Damas-Milner calculus with a restricted 
notion of bounded polymorphism, and allowing multiple types for constants. We 
assume a partially ordered set (T, <) of base types, which forms the subtyping 
hierarchy. 

Types of A°": 



t 
a 

n T2 

a ::= 

Vai<:Ti, . . . ,a„<:T„(r) 



types 

base type {t G T) 

type variable 

function type 
prenex quantified type scheme 

(FF(ri) = (), forall i) 



Given a type r in A°f , we define FV{t) to be the sequence of type variables 
appearing in r, in depth-first, left-to-right order. (Since there is no binder in r, all 
the type variables appearing in r are necessarily free.) Wc write sequences using 
the notation (ai, . . . , q;„). We make a syntactic restriction that precludes the use 
of type variables in the bounds of quantified type variables. 

An important aspect of our calculus, at least for our purposes, is the set of con- 
stants that we allow. We distinguish between two types of constants: base constants 
and primitive operations. Base constants, taken from a set C, are constants repre- 
senting values of base types t £ T. We suppose a function nc ■ C ^ T assigning 
a base type to every base constant. The primitive operations, taken from a set F, 
are operations acting on constants and returning constants.* Rather than giving 
primitive operations polymorphic types, we assume that the operations can have 
multiple types, which encode the allowed subtyping. Wc suppose a function irp 
assigning to every primitive operation / G F a set of types npif), each type a 
functional type of the form t ^ t' (for t, t' e T). 

Our expression language is a typical polymorphic lambda calculus expression 
language. 

Expression Syntax of A°f : 



c 
/ 

Xx:T{e) 
ei 62 

X 

p [n,--- 



monomorphic expressions 
base constant (c G C) 
primitive operation (/ e F) 
functional abstraction 
function application 
variable 

type application 



■* For simplicity, we will not deal with higher-order primitive operations here — they would simply 
complicate the formalism without bringing any new insight. Likewise, allowing primitive oper- 
ations to act on and return tuples of values is a simple extension of the formalism presented 
here. 
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let X = p in e local binding 

p ::= polymorphic expressions 
X variable 

Aai<:Ti, . . . , Q!„<:T„(e) type abstraction {FV{Ti) = { ), for all i) 

The operational semantics is given using a standard contextual reduction semantics, 
written ei — ><: 62- While the details can be found in Appendix A, we note here 
the most important reduction rule, involving constants: 

fc^^. c' iff S{f,c) = c' 

where ^:FxC—^C is a partial function defining the result of applying a primitive 

operation to a base constant. 

As previously noted, we do not allow primitive operations to be polymor- 
phic. However, we can easily use the fact that they can take on many types to 
write polymorphic wrappers. For example, we can write a polymorphic wrapper 
Aa<:T{Xx:a(f x)) to capture the expected behavior of a function / that may be 
applied to any subtype of r. We will see shortly that this function is well-typed. 

The typing rules for are the standard Damas-Milner typing rules, modified 
to account for sub typing. The full set of rules is given in Appendix A. Subtyping is 
given by a judgment A l-<, ti <: T2 and is derived from the subtyping on the base 
types. The interesting rules are: 

ti<t2 A l-<. T2 <: 



A l-<, ti <: t2 A l-<, n T2 <: n 

Notice that subtyping at higher types only involves the result type, following our 
discussion in Sections 2 and 4. The typing rules are given by judgments A; T e : r 
for types and A; F \-^, p : ct for type schemes. The rule for primitive operations is 
interesting: 

For all i and for all t/ such that t/ <: Ti, 

(T'-r){T{/ai,...,</Q„}e7rf(/) f f e F, 

FV{t') = (ai,...,a„) 



A,Q!i <: n, . . . ,Q!„ <: r„;r l-<, f : t' ^ t 



The syntactic restriction on type variable bounds ensures that each Ti has no type 
variables, so each r^' <: Ti is well-defined. The rule captures the notion that any 
subtyping on a primitive operation through the use of bounded polymorphism is in 
fact realized by the "many types" interpretation of the operation. 
Subtyping occurs at type application: 

A;Fh<, p:Vai<:Ti,...,a„<:T„(r) A h<, r{ <: n ... A \- t^ <: Tn 

A;r h<, p [r(, ...,<]: r{T(/ai, . . .,</«„} 

As discussed in the previous section, there is no subsumption in the system: sub- 
typing must be witnessed by type application. Hence, there is a difference between 
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the type ti — > t2 (where ti,t2 € T) and Va<:ti(a t2); namely, the former does 
not allow any subtyping. The restrictions of Section 4 are formalized by prenex 
quantification and the syntactic restriction on type variable bounds. 

Clearly, type soundness of the above system depends on the definition of S over 
the constants. We say that ttf is sound with respect to 6 if for all / £ F and c S C, 
l-<, f c: T implies that d{f, c) is defined and nciSif, c)) = r. This definition ensures 
that any application of a primitive operation / to a base constant c yields exactly 
one value 6{f,c) at exactly one type 7rc('5(/, c)) = r. This leads to the following 
conditional type soundness result for A°": 

Theorem 5.1 

If TTp is sound with respect to 6, l-<, e : r, and e — e', then l-<, e' : r and either 
e' is a value or there exists e" such that e' — e". 

Proof 

See Appendix A. □ 



5.2 The Target Calculus A°" 

Our target calculus, A^^', is meant to capture the appropriate aspects of SML 
that are relevant for the phantom types encoding of subtyping. Essentially, it is 
the Damas-Milner calculus (Damas & Milner, 1982) extended with a single type 
constructor T. 

Types of A?": 



r ::= types 

a type variable 

Ti T2 function type 

T T type constructor T 

1 unit type 

Ti X T2 product type 

a ::= prenex quantified type scheme 



Vai, . . . ,a„(T) 



Expression Syntax of A°": 

e ::= 
c 
/ 

Xx:T{e) 
ei 62 

X 

P [Tl,...,Tn] 

let X = p in e 
p ::= 

X 



monomorphic expressions 
base constant (c e C) 
primitive operation (/ e F) 
functional abstraction 
function application 
variable 

type application 

local binding 
polymorphic expressions 
variable 
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Aai . . . , a„ (e) type abstraction 



The operational semantics (via a reduction relation — >t) and most typing rules 

(via a judgment A;T \-j e : t) arc standard. The calculus is fully described in 
Appendix B. As before, we assume that wc have sets of constants C and F and 
a function 6 providing semantics for primitive applications. Likewise, we assume 
that TTc and ttf provide types for constants, with similar restrictions: 7rc(c) yields 
a closed type of the form T t, while ttfH) yields a set of closed types of the form 
(T Ti) ^ (T T2). The typing rule for primitive operations in A^" is similar to the 
corresponding rule in A°". It ensures that a primitive operation can be given a 
type (possibly with free type variables) if all the substitution instances of that type 
are allowed by the assignment it p. Given two types t and t' in A°", where r' is 
a closed type, we define their unification unify {t,t') to be a sequence of bindings 
((ai, Ti), . . . , (a„, T„)) in depth-first, left-to-right order of appearance of ai, . . . , o;„ 
in T such that T{Ti/ai, . . . ,Tn/an} = r', or if t' is not a substitution instance 
of r. As for A^", given a type r in A°", we define FV{t) to be the sequence of free 
type variables appearing in r, in depth- first, left-to-right order. 

For all r' € 7rc(C) such that 
unify{Ti,T') = ((ai,r{),...,(a„,0,...), 

(n-T2){r{/ni rVn„}G -,-(/) 

A, Q!i, . . . , a„; r K / : Ti ^ T2 

Again, this rule captures our notion of "subtyping through unification" by ensuring 
that the operation is defined at every base type that unifies with its argument 
type. Our notion of soundness of TTp with respect to 6 carries over and we can again 
establish a conditional type soundness result: 

Theorem 5.2 

If ttf is sound with respect to 5,\--r e: r, and e — >t e', then e' : r and either e' 
is a value or there exists e" such that e' — >t e". 

Proof 

See Appendix B. □ 

Note that the types T t, 1, and ti x T2 have no corresponding introduction 
and elimination expressions. We include these types for the exclusive purpose of 
constructing the phantom types used by the encodings. We could add other types 
to allow more encodings, but these suflace for the encodings of Section 3. 



FV{t{) = {ai,...,an) 



5.3 The Translation 

Thus far, we have a calculus A°" embodying the notion of subtyping that interests 
us and a calculus A™ capturing the essence of the SML type system. We now 
establish a translation from the first calculus into the second using phantom types to 
encode the subtyping, showing that we can indeed capture that particular notion of 
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subtyping in SML. Moreover, we show that the translation preserves the soundness 
of the types assigned to constants, thereby guaranteeing that if the original system 
was sound, the system obtained by translation is sound as well. 

We first describe how to translate types in A°". Since subtyping is only witnessed 
at type abstraction, the type translation realizes the subtyping using the phantom 
types encoding of abstract and concrete subtypes. The translation is parameterized 
by an environment p associating every (free) type variable with a type in 
representing the abstract encoding of the bound. 

Types Translation: 

Tlajp = p{a) 
mp = T {t)c 

Tin ^ ralp ^ nnjp ^ T[t21p 

T|[Vai<:Ti, . . . ,a„<:T„(T)]/) = Van, ■ • ■ ,aifei, • • ■,ani, ■ ■ ■ ,ankn{'TlT\p[ai ^ t{^]) 

where = Aln} 
and FV{Tf) = (a^, • • • , otik,) 



If p is empty, we simply write T\t\ for T|r]p. To compute the abstract and concrete 
encodings of a type, we define the functions A and C. 



Abstract and Concrete Encodings: 



Alt} ^ T {t)A 








m ^ T {t)c 






- C[r2l 



The syntactic restriction on type variable bounds ensures that A and C are always 
well defined, as they are never applied to type variables. Furthermore, the above 
translation depends on the fact that the type encodings {t)c and {t)A are expressible 

in the A™ type system using T, 1, and x. 

We extend the type transformation T to type contexts T in the obvious way: 

Type Contexts Translation: 

I 1 

Tlxi : n, . . . , a;„ : r^Jp = Xx : T|ri]p, . . . , a;„ : T|t„]p 



Finally, if we take the base constants and the primitive operations in A°" and 
assume that np is sound with respect to 6, then the translation can be used to 
assign types to the constants and operations such that they are sound in the target 
calculus. We first extend the definition of T to nc and ttf in the obvious way: 
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Interpretations Translation: 

r[7rcl ^ tt'c where 7r^(c) = Tl7rc(c)l 

U-kf} = t^'f where 7r^(/) = {T[t] | r G tt^ (/)} 



We can further show that the translated types do not allow us to "misuse" the 
constants in A^*^: 

Theorem 5.3 

If -kf is sound with respect to 6 in then TfTTi;-] is sound with respect to 6 in 
Proof 

See Appendix C. □ 

We therefore take TJttcI ^'^'l ^[['''fI to be the interpretations in the target cal- 
culus A™. 

We can now define the translation of expressions via a translation of typing 
derivations, £, taking care to respect the types given by the above type translation. 
Wc note that the translation below works only if the concrete encodings being used 
do not contain free type variables. Again, the translation is parameterized by an 
environment p, as in the type translation. 

Expressions Translation: 

'£:|A;rh<, x:t\p = x ' 

f [A;r Ax:r'(e) : rjp 4 Ax:r[T']p(f [e]p) 

f [A;r ei 62 : t\p ^ (f [eilp) f [eajp 

£|A; r l-<, let a; = p in e : t\p = let a; = f in £\e\p 

f[A;rh<.p[Ti,...,T„] :r]p^ 

(^blp) [■rii> • • • jTifci, • • • ,T„i, . . . ,r„fe„] 

where BM^ = (("i, ), • • • , K, r^)) and rf = ^[rf 1 

and FV{tP) = (a^, • • • , ajfe;) and rf = T[t,]/9 

and unify{Tf,Tf) = ((aji, Tji), . . . , (ajfc,, TjfcJ, . . . ) 
£:|A;r h<, X : a]p = x 
5|A;r l-<, Aai<:Ti, . . . ,a„<:T„(e) : a\p = 

Aaii, . . . ,Q;ifei, . . . . . . ,Q;„fe„(f |Ie]p[ai i-^ r/^]) 

where rf- = Aln} and FV{t^) = {an,. . . , ajfc,) 



Again, if p is empty, we simply write £|e| for £"|e]p. The function B returns the 
bounds of a type abstraction, using the environment F to resolve variables. 

Bounds of a Type Abstraction: 

BlxjT = ((q!i,ti), . . . , (a„,r„)) where r(a;) = Vai<:Ti, . . . ,a„<:T„(T) 
S|Aai<:ri, . . . , a„<:r„(e)|r = ((ai,ri), . . . , (q„,t„)) 



Phantom Types and Subtyping 



27 



We use B and unify to perforin unification "by hand." In most programming lan- 
guages, type inference performs this automatically. 
We can verify that this translation is type-preserving: 

Theorem 5.4 

If l-<. e : r, then K £fr^., e : rj : TIt}. 
Proof 

Sco Appendix C. □ 

Theorem 5.4 shows that the translation captures the right notion of subtyping, in 
the sense that interests us, particularly when designing an interface. Given a set of 
constants making up the interface, suppose we can assign types to those constants 
in A™ in a way that gives the desired subtyping; that is, we can write type-correct 
expressions of the form Aa<:t{Xx:a{f x)) with type Wa<:t{a r). In other words, 
the typing ttf is sound with respect to the semantics of S. By Theorem 5.1, this 
means that A^" with these constants is sound and we can safely use these constants 
in A°". In particular, we can write the program: 

let gi = Aa<:ti^{Xx:a{fi x)) in 

let gn = Aa<:ti^{Xx:a{fn x)) in 
e. 

By Theorem 5.4, the translation of the above program executes without run-time 
errors. Furthermore, by Theorem 5.3, the phantom-types encoding of the types 
of these constants are sound with respect to 5 in A°". Hence, by Theorem 5.2, 
A^"^ with these constants is sound and we can safely use these constants in A^*^. 
Therefore, we can replace the body of the translated program with an arbitrary 
A°" expression that type-checks in that context and the resulting program will 
still execute without run-time errors. Essentially, the translation of the let bindings 
corresponds to a "safe" interface to the primitives; programs that use this interface 
in a type-safe manner are guaranteed to execute without run-time errors. 



5.4 Example and Remarks 

In this section, we work through a mostly complete example before turning our 
attention to some general remarks. 

Recall the subtyping hierarchy introduced in Section 2 and here extended to 
include natural numbers and strings. 



atom 




int bool str 
nat. 
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We can encode this hierarchy with phantom types as foUows: 



(atom) A 
{int)A 
{nat)A 
{hoot) A 
{strjA 



a X (/? X 7) 
T a X (/3 X 7) 
T (T a) X (/3 X 7) 



a X (T /3 X 7) 
a X (/3 X T 7) 



{atom)c 
{int)c 
{nat)c 

{booI)c 

{str)c 



1 X (1 X 1) 
T 1 X (1 X 1) 



T (T 1) X (1 X 1) 



1 X (T 1 X 1) 
1 X (1 X T 1). 



We consider two primitive operations double and toString with 

7ri?(double) — {int int, nat —> nat} 
TTi? (toString) = {atom ^ str, int ^ str, nat str, bool ^ str, str^str}. 

We can derive the following typing judgments in A°f , which capture the intended 
sub typing: 

l-<. Aa<:int{Xx:a{douhle x)) : ya<:int{a a) 

l-<, Aa<:atom(Aa;:a(toString a;)) : ya<:atom{a str). 

Applying our translation to these functions yields: 

£lAa<:int{Xx:a{dov.hle a;))] = Aa,P,j{Xx:T (T a x (/3 x 7))(double x)) 
f |Aa<:atom(Aa;:a(toString x))} = Aa,P,^{Xx:T (a x (/3 x 7))(toString x)). 

As expected from Theorem 5.4, we can derive typing judgments that assign the 
translated types to these functions: 

K Aa, /3, 7(Aa;:T (T a x (/? x 7))(double a;)) : 

Va,/?,7(T (T a X (/? x 7)) ^ T (T a X (/? X 7))) 

K Aa, /3,^{Xx:T (a x (/3 x 7)) (toString x)) : 

Va,/J,7(T (q X (/3 X 7)) ^ T (1 X (1 X T 1))). 

Interestingly, we can also derive the following typing judgments: 



The first function type-checks because, of all base types, only T {int)c unifies with 
T (T a X (a X a)), by the substitution (a, 1), and {T {int)c T {int)c} ^ 
TIttfI (double). Likewise, the second function type-checks because, of all base 
types, only T {atom)c, T {int)c, T {nat)c unify with T (T a x (/? x /?)) and 
{T {atom)c T {str)c, T {int)c T {str)c, T {nat)c —* T {str)c} C 
TIttfJ (toString). We can interpret the first as a function that can only be ap- 
plied to integers (but not naturals) and the second as a function that can only 
be applied to atoms, integers, and naturals (but not booleans or strings). Observe 
that while these functions do not capture all of the subtyping available in their 
wrapped primitive operations, neither do they violate the subtyping available. This 



l-T Aa(Ax:T (T a x (a x a)) (double x)) 

Va(T (T a X (a X a)) ^ T (T a X (a x a))) 

\-j Aa,l3{Xx:J {a x {(3 x /3))(toString x)) 

Vq,/3(T (q X (/3 X /?)) ^ T (1 X (1 X T 1))). 
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corresponds to the fact that the second set of types are instances of the first set of 
types under appropriate substitutions for (3 and 7. 

The existence of these typing judgments sheds some light on the practical aspects 
of using the phantom- types technique in real programming languages. Recall that 
the typing judgment for primitive operations is somewhat non-standard. Specifi- 
cally, in contrast to most typing judgments for primitives (like the typing judgment 
for base constants), this judgment is not syntax directed; that is, the type is not 
uniquely determined by the primitive operation. This complicates a type-inference 
system for A"*^. At the same time, we cannot expect to integrate this typing judg- 
ment into an existing language with a Hindley-Milner style type system. Rather, 
we expect to integrate a primitive operation into a programming language through 
a foreign- function interface, at which point we give the introduced function a very 
base type that does not reflect the subtyping inherent in its semantics.^ After in- 
troducing the primitive operation in this fashion, we wrap it with a function to 
which we can assign the intended type using the phantom types encoding, because 
the type system will not, in general, infer the appropriate type. It is for this reason 
that we have stressed the application of phantom-types technique to developing 
and implementing interfaces. 

6 Conclusion 

The phantom-types technique uses the definition of type equivalence in a program- 
ming language such as SML or Haskell to encode information in a free type variable 
of a type. Unification can then be used to enforce a particular structure on the in- 
formation carried by two such types. In this paper, we have focused on encoding 
subtyping information. We were able to provide encodings for hierarchies with var- 
ious characteristics, and more generally, hinted at a theory for how such encodings 
can be derived. Because the technique relies on encoding the subtyping hierarchy, 
the problem of extensibility arises: how resilient are the encodings to additions to 
the subtyping hierarchy? This is especially important when designing library in- 
terfaces. We showed in this paper that our encodings can handle extensions to the 
subtyping hierarchy as long as the extensions are always made with respect to a 
single parent in the hierarchy. We also showed how to extend the techniques we 
developed to encode a form of prenex bounded polymorphism, with subsumption 
occurring only at type application. The correctness of this encoding is established 
by showing how a calculus with that form of subtyping can be translated faithfully 
(using the encoding) into a calculus embodying the type system of SML. 

It goes without saying that this approach to encoding subtyping is not without 
its problems from a practical point of view. As the encodings in this paper show, 
the types involved can become quite large. Type abbreviations can help simplify the 

^ In general, foreign-function interfaces have strict requirements on the types of foreign functions 
that can be called. Due to internal implementation details, language implementations rarely 
allow foreign functions to be given polymorphic types or types with user defined datatypes, 
both of which are used by the phantom types encodings. 
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presentation of concrete types, but abstract encodings require type variables and 
those variables need to appear in the interface. Having such complex types lead 
to interfaces themselves becoming complex, and, more seriously, the type errors 
reported to the user are fairly unreadable. Although the process of encoding the 
subtyping hierarchies can be automated — for instance, by deriving the encodings 
from a declarative description of the hierarchy — we see no good solution for the 
complexity problem. The compromise between providing safety and complicating 
the interface must be decided on a per-case basis. 

We also note that the source language of Section 5 provides only a lower bound 
on the power of phantom types. For example, one can use features of the specific 
encoding used to further constrain or refine the type of operations. This is used, 
for instance, by Reppy (1996) to type socket operations. There is yet no general 
methodology for exploiting properties of encodings beyond them respecting the 
subtyping hierarchy. 
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A The Calculus 

Values: 

V ::= values 

c base constant (c G C) 

f primitive operation (/ e F) 

Xx:T{e) functional abstraction 



Evaluation Contexts: 

E ::= evaluation contexts 
[ ] empty context 

E e application context 

V E argument context 

E [ti , . . . , T„] type application context 



Operational Semantics: 

(Ax:T(e)) V — ><, e{v/x} 
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(Aai<:Ti,...,a„<:T„(e)) [t(,...,<] — ><, e{T{/ai, . . . , </a„} 
let X = p in e — ><, e{p/a;} 
/c^<, c' ifr S{f,c) = c' 
E[ei\ — E[e2\ iff ei — 62 



The function Jii^xC^C is a partial function defining the result of applying a 
primitive operation to a base constant. 



Typing Contexts: 


r 


type environments 




empty 


r,x:T 


type 




type scheme 


A ::= 


subtype environments 




empty 


A,a<:T 


subtype 


Judgments: 


l-<, A ctxt 


good context A 


A T type 


good type r 


A h^ . (7 scheme 


good type scheme a 


A i-<^ r ctxt 


good context F 


A h<, Ti <: T2 


type Ti subtype of T2 


A;ri-<, e:r 


good expression e with type r 


A;rh, p-.a 


good ("xprc'ssion /) witli t> p(> sclit^mo a 



Judgment A ctxt: 

h<, A ctxt A l-<, T type 



l-<, • ctxt l-<, A,a <:t ctxt 



Judgment A l-<, r type: 

I 1 

l-<, A ctxt a e dom(A) A l-<, n type A l-<, T2 type 



A h<, t type A a type A l-<, n — > T2 type 



Judgment A l-<, cr scheme: 

A,ai <: n, . . . ,a„ <: t„ I-<, t type 



A Vai<:ri, . . . , a„<:T„(T) scheme 
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Judgment A l-<, T ctxt: 



A l-<. r ctxt A l-<. T type 


A l-<. r ctxt A h<. a scheme 


A l-<, ■ ctxt A l-<, r, a; : r ctxt 


A l-<, T,x : a ctxt 


Judgment A l-<, n <: T2- 



tl < t2 



A l-<, T <: r A,a <: T \-^., a <: T A l-<, ti <: t2 

A l-<, T2 <: T3 A l-<, n <: T2 A l-<, T2 <: T3 



A l-<, n ^ r2 <: Tl ^ rs A l-<, n <: T3 



Judgment A; F l-<; e : r: 



A;rh<, c:7rc(c) 



{cgC) 



For all i, and for all r/ such that |-<: t/ <: r^, 

(T'-T){r{/ai,...,</a„}e7r^(/) / f € F, 



A,ai <: n, . . . ,Q!„ <: r„;F l-<: f : t' ^ t 
A l-<, F ctxt A; F, X : T l-<^ e : r' 



F1/(t') = {ai,...,an) 



A;T,x:t\-^..x:t A;T \-^, Xx:T{e) : t t' 
A; F h<, ei : Tl ^ T2 A; F l-<. 62 : n 

A;F l-<, ei 62 : T2 

A;ri-<, j3 : Vai<:Ti, . . . ,a„<:T„(T) A l-<, t{ <: n ... A t^ <: t„ 

A;FI-<, p [t{,...,t;] :T{T{/ai,...,</a„} 
A; F, a; : fj l-<, e : T A; F l-<, p : a 



A; r l-<, let a; = p in e : T 



Judgment A; F \-^, p : a: 



A l-<: F ctxt A, ai <: Tl, . . . , a„ <: t„; F I-<, e : t 

(ai,...,a„ ^ A) 



A;ri-<, Aai<:Ti, . . . ,a„<:T„(e) : Vai<:Ti, . . . ,a„<:T„(T) 
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A . 1 Proofs 

The proof of soundness for A™ is mostly standard, relying on preservation and 
progress lemmas. For completeness, we present all the lemmas needed to derive the 
proof, but leave most of the straightforward details to the reader. 

Lemma A.l 

(a) Monomorphic expression substitution preserves typing: 

— If A; r, a; : r' e : r and A; V e' : r', then A; V e{e'/x} : r. 

— If A; r, a; : t' h^.,p:a and A; T h<, e' : r', then A; T h<^ p{e'/x} : t. 

(b) Polymorphic expression substitution preserves typing: 

— If A; r, x : a' l-<, e : r and A; T h<, p' : a', then A; T \-^., e{p'/x} : r. 

— If A; r, a; : a' \-^..p:a and A; T h^, p' : a', then A; T \-^., p{p'/x} : a. 

(c) Type subsumption preserves subtyping: 

— If A, a <: t' \-^, Ti <: T2, and r" <: t' then A, a <: r" l-<, n <: T2. 

(d) Type subsumption preserves typing: 

— If A, a <: r'; T e : r and r" <: r', then A, a <: r"; T\-^,e: r. 

— If A, a <: r'; T l-<, p : ct and r" <: r', then A, a <: r"; T l-<, p : ct. 

(e) Type substitution preserves subtyping: 

— If A, a <: t' I-<, n <: T2, then A l-<, tiIt'/Q!} <: T2{T'/a}. 

(f) Type substitution preserves typing: 

— If A, a <: t'; T l-<, e : t then A; r{T'/a} e{T'/a} : t{t' /a}. 

— If A, a <: r'; T l-<, p : then A; rfrVa} p{r7a} : CT{r7a}. 

(g) Canonical forms: 

— If l-<, V : t, then v has the form c (for c £ C). 

— If u : Tq ^ T;,, then either v has the form / (for f & F) or v has the 
form Xx:Ta{ea)- 

— If l-<, p : yai<:Ta,i, . . . ,an<'-Ta,n{Ta), then p has the form 

Aai<:Ta,l, . . ■ , an<:Ta,n{ea) 

Proof 

(a) Proceed by simultaneous induction on the derivations A;r,x : t' I-<, e : r and 
A; r, X : r' h-<, p : a. 

(b) Proceed by simultaneous induction on the derivations A;r, a; : a' l-<, e : r 
and A; r, X : cr' p : cr. 

(c) Proceed by induction on the derivation A, a <: r' l-<. ti <: T2. 

(d) Proceed by simultaneous induction on the derivations A, a : t';T I-<, e : r 
and A, a : t';T p : a. We give the one interesting case of the induction. In 
the primitive operation case, e = f {f G F), FV{t) = (ai, . . . and for all 
Ti <: ri,...,T* <: r„, we have r{Ti /ai, . . . , r*/a„} G 7rF(/). If a ^ the 
result is immediate. If a = ai, then for all r* <: n, . . . ,t* <: r', . . . ,r* <: r„, 
r{Ti /ai, . . . , r*/a, . . . , T*/a„} S 7r_F(/) and A r" <: t' implies that for all 
Ti <: Ti,...,r* <: T",...,r* <: t„, t{ti /ai, . . . , T*/ai, . . . , T*/a„} G 7rF(/). 
Thus, A,a<: t";T\-^, f : r. 
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(e) Proceed by induction on the derivation A, a <: r' l-<, n <: T2. 

(f) Proceed by simultaneous induction on the derivations A, a <: r'lF l-<, e : r 
and A, a <: r'; F p : a. We give the interesting cases of the induction. 

In the primitive operation case, e = / (/ G F), FV{t) — (ai, . . . , Q!„), and 
for all tI <: ti,...,t* <: Tn we have t{ti /ai, . . . ,T*/an} S t^fU)- Note 
/{r'/a} = /. If a ^ aj, the result is immediate. If a = aj, then for all <: 
Ti,...,T* <: r',...,T* <: t„ we have r{TiVai, . . . , T*/a, . . . , r*/Q!„} G ttfU), 
which implies that for all rj* <: ti,...,t*_i <: Ti_i,r*^_j <: Tj+i,...,T* <: 
r„, we have T{r7a}{Ti /«!,•••, r*_i/Q;i_i, T*,_i/ai+i, r*/a„} e ttfC/)- Thus, 
A;r{rVa} h,.. f : t{t' /a}. 

In the type abstraction case, p = Kai<:Ta,i, ■ ■ ■ ,oin<'-Ta,n{e-a), cr = 
Vai<:ra,i, . . . ,a„<:Ta,n(Ta), and A, a <: T',ai <: Ta,i,...,a„ <: ra,„;r l-<, 
Assume ai,...,a„ ^ a. Note (Aai<:Ta,i, . . . , Q!n<:7-a,n(ea)){''"VQ!} = 
Aa'i<:ra,i, . . . ,a„<:Ta,„(ea{T7a}) and {yai<:Ta,i, . . . ,a„<:Ta,n{Ta){T' /a} = 
Vai<:T„.i. . . . ,an<-Ta.n{Ta{T' /a}) (bccausc type variables are precluded from 
the types of quantified type variables). Furthermore, A,ai <: Ta^i, ■ ■ ■ ,a„ <: 
Ta,n,Oi <: t';T I-<, Ca ■ Ta- By the induction hypothesis, A, ai <: 
ra,i,...,a„ <: Ta,n;T{T'/a} ea{T'/a} : Ta{T'/a}. Hence, A;r{T'/a} l-<, 
(Aai<:ra,i, . . ■ ,an<:Ta,n{ea)){T' /a} : a{T'/a}. 

(g) For the first part, proceed by case analysis of the derivation l-<, v : t. For 
the second part, proceed by case analysis of the derivation l-<, v : Ta ^ Tb- For the 
third part, proceed by case analysis of p. □ 

Theorem 5.1 

If TTF is sound with respect to 5, \-^.. e : t and e — ^ e', then l-<; e' : r and either 
e' is a value or there exists e" such that e' — e". 

Proof 

This is a standard proof of soimdncss, relying on progress and preservation lemmas: 

• Progress: if ttf is sound with respect to S and l-<, e : r, then either e is a 
value or there exists e' such that e — ><, e'. This follows by induction on the 
derivation h^-. e : t. The only interesting case is the application case e = ei 62 
when ei has the form / (for / G F) and 62 is a value. Then Ta ^ t = ta ^ t ioi 
ta,t G T and ta —>■ t € T^rif) by the typing judgment for primitive operations. 
By part 1 of Lemma A. 1(g), 62 has the form c (for c G C). Hence, l-<, f c:t 
and 5{ f, c) is defined by the definition of -kf sound with respect to 6, and the 
primitive step applies to e. 

• Preservation: if ttf is sound with respect to 8, l-<, e : r and e — e', then 
l-<, e' : T. This follows by induction on the derivation l-<, e : t. The only 
interesting case is the application case e = ei 62, when e\ = f (for f £ F), 
€2 = c (for c e C), and e' = 6{f, c). the result follows by the definition of np 
sound with respect to 6. 

To prove soundness, we assume e : t and e — e'. Then e — e' for 
some n. Proceed by induction on n. In the base case, the theorem is equivalent 
to progress. In the step case, the inductive hypothesis, preservation, and progress 
suffice to prove the theorem. □ 
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B The Calculus 


Value: 




V ::= 


values 


c 


base constant (c € C) 


/ 


primitive operation (/ G i^) 


A.r:r(r) 


fuiictioiial alwtractiou 


Evaluation Contexts: 


E ::= 


evaluation contexts 


[] 


empty context 


E e 


application context 


V E 


argument context 


E [ri,...,r„] 


type application context 


let X = E in e 


local binding context 



Operational Semantics: 

I 1 

{Xx:T{e)) V — >T e{v/x} 

(Aai,...,Q;„(e)) [t{,...,<] — >-r e{T{/ai,...,T^/an} 
let X = p in e — >t e{p/x} 
fc^,c' iff 6{f,c)=c' 

E[ei] — £'['■2' iff < i_ — -T < 2 



The function S : F x C C is a, partial function defining the result of applying a 
primitive operation to a base constant. 



Typing Contexts: 



r ::= 


type environments 




empty 


r,x:T 


type 


r,x : a 


type scheme 


A ::= 


type variable environments 




empty 


A.n 


type variable' 


Judgments: 


A i-T r ctxt 


good context F 


A l-T T type 


good type r 


A\-j a scheme 


good type scheme a 


A; r K e : T 


good expression e with type r 


A;r : cr 


good expression p with type scheme a 
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Judgment A h-r F ctxt: 



A l-T r ctxt A h-r 


F ctxt 


A l-T • ctxt A l-T r, a; : T ctxt A I-t T, 


X : a ctxt 


Judgment A I-t r type: 


h-r A ctxt n G doin(A) 


A hj Tj type A hj To t>'p(^ 


A l-T f type A l-T a type 


A l-T n ^ T2 type 


Judgment A I-t a scheme: 


A,ai, . . . ,q:„ K T type 




A l-T Vai, . . . , a„(T) scheme 




Judgment A; F I-t e : r: 


(ceC) 

A; F hy c : ncic) 




For all t' G tic{C) such that 
unify{Ti,T') = ((ai,T{),...,(a„,r^),...), 
(n T2){r{/ai, . . .,T^/an} G -^fU) 


V fF(ri) = (ai,...,a„) J 



A, ai, . . . ,a„;F K / : n ^ T2 



A l-T F ctxt A; F, X : r l-T e : r' 



A; F, a; : T K X : r A; F K Aa;:r(e) : t ^ t' 






A; F l-T ei : n ^ T2 A; F 62 : n 
A; F K ei 62 : r2 






A;F : Vai, . . . ,a„(r) 


A; F, a; : cr K e : T 




A;F K p [n, . . . ,r„] : r{Ti/ai, . . . ,r„/a„} 


A; F l-T let x = 


p in e : T 


Judgment A; F I-t p : ct: 


A l-T F ctxt A, ai, . . . , a„; F K e : r 

(ai,. 

A;F l-T Aai, . . . ,a„(e) : Vai, • • • ,a„(T) 


• • , an ^ A) 
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B.l Proofs 

The proof of soundness for A^" is mostly standard, relying on preservation and 
progress lemmas. As we did for A^", we present all the lemmas needed to derive 
the proof, but leave most of the straightforward details to the reader. 

Lemma B.l 

(a) Monomorphic expression substitution preserves typing: 

— If A; r, X : r' K e : T and A; T K e' : r', then A; T e{e'/x} : r. 

— If A; r, x : r' K P : o- and A; T K e' : r', then A; T K p{e'/x} : r. 

(b) Polymorphic expression substitution preserves typing: 

— U A;T,x : a' \-j e-.T and A; T K p' : a', then A; T \-j e{p'/x} : r. 

— UA;T,x:a'\-jp:a and A; T K p' : a', then A; T K p{p'/x} : a. 

(c) Type substitution preserves typing: 

— If A, a; r K e : T then A; T{T'/a} K e{T'/a} : t{t' jo). 

— If A, a; r K p : (7 then A; V{t' ja] K p{t' ja] : a{T'/a}. 

(d) Canonical forms: 

— If l-T w : T T, then v has the form c (for c € C). 

— If V : Ta ^ Tb, then either v has the form / (for f & F) or v has the 
form Xx:Ta{ea)- 

— If h-r p : Vai, . . . , an{Ta), then p has the form Aai, . . . , a„(ea) 
Proof 

(a) Proceed by simultaneous induction on the derivations A; F, a; : r' e : r and 

A; F, X : t' p : a. 

(b) Proceed by simultaneous induction on the derivations A; F, a; : u' e : t 
and A; F, a; : cr' hy p : a. 

(c) Proceed by simultaneous induction on the derivations A, a; F e : r and 
A, a; F p : a. Wc prove the interesting cases of the induction. 

In the primitive operation case, e = / (/ G F), t = ti T2, 
FV{ti) = (ai,...,a„), and for all r* G 7rc(C) such that unify{T^,T{) = 
((ai,T{),..., («„,<),...), wc have n ^ T2{T{/ai, . . . , G ttfC/)- Note 

/{r'/a} = /. If a 7^ a; for any i, the result is immediate. If a = 0;^ for 
some i (without loss of generality, let i = 1), then for any r* G i^ciC) such 
that unify {t^, ti{t' /ai}) = ((02, T2), . . . , (a„, r^), . . . ), we have unify{n,Ti) = 
((Q:i,T'),(a2,r^),...,(a„,0,...), so that (n ^ T2){T7a}{T2/Q!2, • . • , </a„} = 
(ri ^ T2){r'/ai,r^/a2, • • € tt^ (/). Thus, A;F{T7a} K / : T{r'/a}. 

In the type abstraction case, p = Aai, . . . , a„(ea), a = Vai, . . . , Q:„(Ta), 
and A, a, Qi, . . . , Q!„; F : Ta- Assume Q!i,...,Q!„ 7^ a. Note 

(Aai, . . . ,a„(ea)){r7a} = Aai, . . . , a„(ea{T7Q:}) and (\/ai, . . . ,an{Ta)){T' /a} = 
yai, . . . ,an{Ta{T' /a}) (because type variables are precluded from the types of 
quantified type variables). Furthermore, A, ai, a; F \-j Sa ■ Ta- By the 

induction hypothesis, A,ai, . . . ,an,T{T' /a} hy Bair'/a} : Ta{T'/a}. Hence, 
A; F{T7a} K (Aai, . . . , a„(e„)){r7a} : a{T'/a}. 

(d) For the first part, proceed by case analysis of the derivation \-j v : T t. For 
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the second part, proceed by case analysis of the derivation \-j v : Ta ^ t^. For the 
third part, proceed by case analysis of p. □ 

Theorem 5.2 

If TTF is sound with respect to (5, hj e : r and e — >^ ^'j then e' : r and either e' 
is a value or there exists e" such that e' — >t e". 

Proof 

This is a standard proof of soundness, relying on progress and preservation lemmas: 

• Progress: if np is sound with respect to S and hy e : t, then cither e is a 
value or there exists e' such that e — >t e'. This follows by induction on the 
derivation e : r. The interesting case of the induction is the application 
case e = ei 62 when ei has the form / (for f G F) and 62 is a value. Then, 
Ta ^ T = ta —* t for ta,t G T and ta t €L T^pi f) by the typing judgment for 
primitive operations. By part 1 of Lemma B.l, 62 has the form c (for c £ C). 
Hence, / c : r and 6{f,c) is defined by the definition of np sound with 
respect to S. Thus, the primitive step applies to e. 

• Preservation: if np is sound with respect to 5, e : t and e — >t e', then 
hy e' : T. This follows by induction on the derivation hj e : r. Again, the 
interesting case is the application case e = ei 62 when ei = / (for f G F), 
62 = c (for c e C), and e' = (5(/, c). The result follows by the definition of np 
sound with respect to 5. 

To prove soundness, we assume e : r and e — >^ s'- Then e — e' for some n. 
Proceed by induction on n. In the base case, the theorem is equivalent to progress. 
In the step case, the inductive hypothesis, preservation, and progress suffice to prove 
the theorem. □ 

C Translation Proofs 

Theorem 5.3 

If -Kp is sound with respect to 6 in then T|[7rir] is sound with respect to 5 in 
Proof 

We need to show that for all / G and c S C such that / c : r for some r, then 

5{f. c) is defined, and that TlTTci{S{f, c)) = t. Given f € F and c G C, assume that 
hy / c : T. This means that f : t' ^ t and that hy c : t'. From K / : r' — > r, 
we derive that for ah r* G T|7rcl(C) such that unify {t* ,t') ^ (since r' and r* 
arc both closed types), r' r G T|7ri?J|(/). By definition of T, and by assmnption 
on the form of ttf, this means that r' — > r is of the form T|t'] T\t\, with 
Tlt'l = t' and T|t]| = r. Hence, l-<, f : t' ^ t. From hy c : r', we derive that 
rji'l = r' = T|7rcl(c) = T|7rc(c)l. Hence, 7rc(c) = t', and l-<. c : i'. We can 
therefore infer that h<. f c : t. Therefore, by soundness of np with respect to S in 
A°", we get that (5(/, c) is defined, and that ttcW, c)) = Thus, T|7rcl((5(/, c)) = 
Tl7rc(5(/, c))l = ntj = T, as required. □ 
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The following lemma, relating the correctness of the subtype encoding and sub- 
stitution, is used in the proof of Theorem 5.4. 

Lemma C.l 

For aU t,t' , and r with FV{t) C (a), if = {t)A, FV{t^) = (cci, . . . , a„), 

and umfyi{t')c,t^) = ((ai, n), . . . , (a„, r„), . . . ), then T[r{i7a}l = T[Tl[a ^ 
t^]{Ti/ai, . . . ,T„/a„}. 

Proof 

We proceed by induction on the structure of r. 

For T = a, we immediately get that ^[T{t'/Q!}l = ^[^1 = {t')c- Moreover, we 
have T[t'][q: t^]{Ti/ai, . . . ,T,Jan} = t^{ri/ai, . . . , T„/a„} = {t')c, by the 
assumption on the unification of {t')c and t^. 

For T = t* for some t* , then Tlrji'/a}] = Tlr] = (r)c. More- 
over, TlTj[a ^ t^]{Ti/ai,...,Tn/an} = T|f*][a ^ t^]{Ti/ai, . . . , r„/a„} = 
(^*)c{Ti/ai, • • • ,t„/q!„} = (t*}c- 

Finally, for r = r' ^ r", we have T|(r' ^ T"){t7a}l = T|r'{t7a} ^ 
r"{t7a}l = T|r'{t7a}]l ^ TlT"{t'/a}}. By applying the induction hy- 
pothesis, this is equal to T[t'][q! t^]{Ti/ai, . . . , r„/a„} ^ T|t"][q: 
t^]{Ti/ai, . . . ,T„/a„} = T|t' ^ T"][a t-^lln/ai, . . . ,T„/a„}, as required. □ 

Theorem 5.4 

If l-<, e : r, then K f I^<: e : r] : T|r]. 
Proof 

We prove a more general form of this theorem, namely that if A; F l-<, e : r, then 
T[Al;TlrlpA K f[A;r e : rjpA : TfrlpA, where: 

T|[q!i <: n, . . . ,Q!„ <: r„] = an, . . . , aik^, • • • , a„i, . . . ,Q!„fe„ 

where = ^[tjI 
and FV{t^^) = {an , . . . , a^fc, ) 

and for A of the form ai <: ri, . . . , q;„ <: r„, 

PA = {ai i-^Tf-,...,a„i-^ T^}. 

Similarly, we show that if AjF l-<, p : a, then T|A];T|r]|pA K f[A;r l-<, p : 
crjpA '■ ^|f]PA- We establish this by simultaneous induction on the derivations 
A; F l-<, e : r and A; T\-^.,p: a. 

For variables. A, F x : t implies that x : r is in F. Hence, x : T|r]/9A is in 
rplpA- Hence, r[Al;r[FlpA K x : TItIpa- Similarly for A;F h<, x : a. 

For constants c e C, if A;F l-<, c : r, then we have 7rc(c) = r. Hence, 
^Ii'c(c)l/5A = ^Hpa, and by definition, T|[7rclPA(c) = T|[t]pa- This implies 
T|A];r[F] Kc:r[TlpA. 

For operations / G -F, if A, ai <: Ti,...,a„ <: t„;F / : r' — »■ 

r (where FF(r') = (ai, . . . , Q!„)). Hence, for all t- <: r,, we have (r' — > 
T){r(/Q;i, . . . ,T'Jan} G TTpif)- Note that this implies that each t[ is of the form 
t[ for some f-, due to the restrictions imposed on tt^. Furthermore, also due to the 
restrictions imposed on ttf, we must have that r' is either t' for some t' , or a type 
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variable ai. We need to show that for all t* G T\'Kc\{C), if unifyir* ,T\t'J) = 
((ai,Ti),...,(a„,r„),...), then T|t' t]]{ti/q:i, . . . , t„/q!„} G T|7r_F](/). Take 
an arbitrary r* G T|7rcl(C). By restrictions on ttc, t* is of the form {t*)c for some 
t* G 7rc(C). Now, consider the different forms of t'. In the case t' = t', we have 
T|t'] = {t')c, so that if unify{{t*)c, {t')c), then = t' . Moreover, because we as- 
sumed that concrete encodings did not introduce free type variables, then FV{t') = 
0. Thus, T[[t' ^ r] = T[[t'| ^ T|r] G TIttfK/) follows immediately from the fact 
that r' ^ T G 7rp'(/). In the case that t' = ai, then T|t']1p = {t[)A- Let = 
(aii,...,aifei}. Assume unify {{t*)c,t"^) = ((an, n), . . . , (aifc^ , TfcJ, . . . ). Because 
the encoding is respectful, unify {{t*)c,t'^) 7^ if and only if t* < t-\_, that 
is, t* <: ti. By assumption, we have (t' T){t*/ai} G TTp{f). Therefore, 
r|(T' ^ T){r/ai}l G riTT^K/). By Lemma C.l, r[(r' ^ T){r/ai}l = r[r' ^ 
Tj{ri/aii, . . . ,T/t;^/ai/t;^}, and the result follows. Since r* was arbitrary, we can 
therefore infer that TJA], an, . . . , au^, . . . , . . . , a„fe„; T|r|/9A[Q!i 1-^ rf] K 

For abstractions, if A; F Aa;:r'(e) : r' — > r, then A; F, a; : r' l-<, e : r. By the 
induction hypothesis, T|A]; T|[r]pA; a; : T|t']pa K ^Jel/OA : TfrlpA, from which 
one can infer that T[Al;T[rlpA K Ax:T[T'IpA(f Hpa) : T[t'1pa ^ T^pA, 
which yields T[A1;T|F1pa K Aa;:T[T'lpA(f Hpa) : Hr' ^ tIpa. 

For applications, if A; F l-<, ei 62 : r, then for some r'. A; F l-<, ei : r' — > r and 
A; F 62 : r'. By the induction hypothesis, we have T[A];T|r]]pA I^t ^[ei] : 
r[r' ^ rl, so that r[A];T[FlpA f [ej : Tlr'l ^ TH, and TIAljTplpA K 
£[62! : Tlr'l This yields that T[Al;TlFlpA K (^IbiIpa) f Ie2lPA : r[rlpA. 

For local bindings, if A;F l-<, let x = p in e : t, then for some a we have 
A;F,a; : a e : r and A;r p : a. By the induction hypothesis, we have 
r[Al;T[F]pA,:r : TlajpA K : T[t]pa and TIAIjTIFIpa £[p]pA : 

THpa. Thus, we have T[AI; TplpA let x = EjpjpA in EiejpA : T|t1pa. 

For type applications, we have A;F p [t[,...,t^] : r. Then for all 

(Q!i,Ti) in B|p1F, wc have A; F p : Vq!i<:ti, . . . , Q!„<:T„(r'), A \-^, 

Tj' <: Ti for all i, and r = r'{r{/Q;i, . . . , r^/a^}. By the induction hypoth- 
esis, T[A1;T|F1pa K £Mpa ■■ T[Vai<:ri,...,a„<:r„(T')l/OA. Let = 
Alnl and FF(r^) = (Q:,;n . . . , a.fc,). Thus, TIAliTplpA K ^Mm : 
Van, • • • ,Q!ifei, . . . ,a„i, . . . , a„fc„(T|T'|pA[aj ^ r/^]). Wc know that A \-^, t[ <: n 
for all i, so we have that unify{T^,TlTijpA) = ((aii,Tii), . . . , {aiki,Tiki), ■ ■ ■ ), and 
T[A1;TIF1pa K ^Mpa [ '^11 5 • • • ? '^Ifci ? • • • i '^nl 5 • • • 5 '^nkn 
required. 

For type abstractions, we have A;F l-<, Aai<:Ti, . . . , a„<:T„(e) : 
Vai<:ri, . . . , a„<:r„(T). Thus, we have A l-<, F ctxt, that is, the type vari- 
ables in F appear in A, and moreover A,ai <: Ti,...,a„ <: t„;F h<. e : 
T. Let rf = Alnj and i^l^(r/^) = {an , . . . , aik^) , for 1 < i < n. Let 
Pa — Pa [di , • • ■ , Q:„ h-»- t^] . By the induction hypothesis, we have 

TlAl,an,...,aik^,...,ani,...,a„k^;TlTjp'^ K S^jp'^ : T|t]p^. ^Prom this 
we can infer that T|A];T|F]p^ K Aan, • • • : au-j , . . . , a„i, . . . , a„fe„ (f [cJpa) : 
Van, . . . , aifci , . . . , a„i, . . . , a„fc„ (TItJpa): which is easily seen equivalent to 
r[A];r|F]pA K fIAai<:Ti,...,a„<:T„(e)lpA : T|Vai<:Ti, . . . , a„<:T„(r)]pA. 
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(We can replace T|r]/9^ by T|r]pA by the assumption that F is a good context 
in A.) □ 
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